1. The Field of the Invention
The present invention relates to systems, methods, and computer program products for transferring data packets. More particularly, the present invention relates to systems, methods, and computer program products for transferring USB data packets.
2. Background and Relevant Art
Users of computerized systems today often employ many different peripheral devices (or “components”) with computerized systems in order to accomplish a variety of different purposes. For example, a user's computerized system can include an internally connected Central Processing Unit (CPU) and a storage device, which, together, can be suitable for processing very large data sets. As well, the user's computerized system can include separate, externally-connected components (e.g., a printer, a video game controller, etc.), which can enable the computerized system to be useful for drawing diagrams, for playing video games, etc.
Just as there are several types of components for use with computerized systems, so also are there many different hardware and software communication means by which such components send data to be processed by the computerized systems. For example, some internally connected components communicate data to a computerized system through a Small Computer System Interface (SCSI) protocol, or through a Peripheral Component Interconnect (PCI) protocol. Other, externally-connected components might, however, communicate with a computerized system through a variety of other interfaces including a Universal Serial Bus (USB) interface, a FireWire (IEEE 1394) interface, an Ethernet (IEEE 802.3) interface, a wireless (IEEE 802.11) interface, a Bluetooth interface, and so forth. Each of these different interfaces can use unique data communication protocols, such that each interface can provide a user with certain data communication advantages.
In some cases, the protocol that a user implements with a component can be dictated by convenience; in other cases by protocol advantages. For example, an externally connected printer can include an Ethernet port, a serial or parallel port, and a USB port. If the data transfer speeds between the user's computerized system and the printer are irrelevant for the user, the user can connect the printer based solely on the computerized systems' available communication ports. Alternatively, if data transfer speed is an issue for the user, the user can prefer to connect the printer through a port that implements a USB or Ethernet communication protocol.
Presently, USB interfaces and protocols are commonly used with certain peripheral devices such as plug-and-play devices (e.g., printers, scanners, video game controllers, digital cameras, Personal Device Assistants—PDAs). This is partly due to the ubiquity of USB interfaces on host computer systems into which the peripheral devices are intended to transfer data, as well as partly due to the speed by which a USB protocol can transfer the data. By contrast, devices transferring data at much longer rates might use protocols such as a firewire protocol, which is optimized by data transfer speeds that can be tens and hundreds of times faster than some USB protocols (e.g., USB version 1.1). In any case, device drivers that rely on data transfers through the USB interface and protocol comprise device drivers using the Network Device Interface Specification (NDIS), Bluetooth drivers for wireless transmissions, Human Interface Device (HID) drivers, and so forth. Such device drivers transfer data between the device and host computer system using the USB protocol stack.
FIG. 1 illustrates a common prior art example where a client driver uses the USB protocol stack (e.g., NDIS, Bluetooth, HID, etc.) to request and receive data from a USB-connected device. As shown, a prior art host computer system 100 can include a client driver 120 that interfaces with a USB protocol stack 130, and a host controller 110 that interfaces with a peripherally-connected USB device 105 through a host controller driver (not shown). In a typical USB environment, a client driver 120 submits one or more data requests 140 to a USB device 105 through the USB protocol stack 130 and host controller 110. Each request 140 requires the USB protocol stack 130 to process different aspects of the request through different modules 135.
This processing can comprise such instructions as placing the request 140 into the host controller 110 processing schedule, and telling the host controller 110 where to place data received from the USB device 105. The host controller 110 then follows its processing schedule. Once the host controller 110 reaches a point in its processing schedule where it is to process request 140, the host controller 110 sends an appropriate information request to the USB device 105. If the USB device 105 has any information to send, the USB device 105 will then send the information to the host controller 110.
When the host controller 110 receives the information from the USB device 105, the host controller 110 might perform one or more actions on the received information, and then send the completed request message 150 (and received information) back up through the USB stack 130 to the client driver 120. Along the way, the various USB protocol layers 135 in the USB stack 130 might then process the information by converting the received information into some sort of meaningful data. The USB protocol layers 135 might also remove the request 140 from the host controller 110 processing schedule.
The client driver repeats this request-and-receive operation continually with the host controller so that the client driver can maximize the amount of information it receives and processes from the USB device. One can appreciate that this continual sending requests and receiving completion notices (sometimes called “ping-pong IRPs”—i.e., ping-pong I/O request packets) can be relatively resource-intensive, particularly when used for protocols where low-latency is important. For example, a client driver for a video game controller might send down two or three requests for relatively small amounts of data at a time. In such a case, the amount of resources necessary to schedule and process the two or three short data requests through the protocol stack can approach the time to receive and process each short data packet coming back up through the protocol stack from the video game controller. Consequently, the amount of resource overhead for each short request can result in inconsistent feed back or output delay times between when a user enters input into a USB device, and when the host computer system processes the input into some form of appreciable output.
What is needed, therefore, are systems, methods, and computer program products that reduce the overhead that would otherwise be needed to process data packets through a protocol stack, particularly in protocols where low-latency is important. In particular, solutions are needed to allow protocols such as some networking (IP) protocols, HID, and USB Bluetooth radio communication protocols implemented over a protocol stack (e.g., the USB protocol stack) to utilize the respective protocol stack and host controller more efficiently.